Power Tools 1993 November - Disc 2/Power Tools Plus (Disc 2 of 2)(November 1993)(HP).iso/hotlines/wsyhl/cosewp/cosewp.txt

Text File | 1993-06-20 | 34KB | 883 lines

                   WHITEPAPER ON OPEN SYSTEM

                        PROCESS ACCELERATION:

                        A Common Open Software Environment

 ________________________________________________________________
______


June 8, 1993

                                         OVERVIEW

The common open software environment process came into being as
six of the major UNIX System suppliers recognized that more
effective cooperation was the key to meeting the demands of
users for consistency and interoperability among software
suppliers. While the initial announcement highlighted specific
technology areas, the intent of the companies at the
announcement was to accelerate the process by which open system
software specifications are defined and submitted to recognized
industry standard forums. Of course, this can be achieved only
if the open system industry rallies around the proposed process
acceleration. The purpose of this whitepaper is to lay out
principles for such process acceleration and then to stimulate
its adoption, benefiting customers and the industry through
increased growth and innovation in the open system marketplace,
in which the companies will continue to compete vigorously. The
proposed process acceleration is intended to work with existing
industry organizations to achieve faster consensus among more
vendors.

This whitepaper incorporates input from sources throughout the
open software industry as a result of many reviews and
intermediate drafts. Nevertheless some important points will
have been overlooked and further evolution will be necessary for
the open software industry to continue to improve its
competitive postion. Feedback and conversation are encouraged
through the avenue given at the end of this paper.

The audience for this whitepaper includes OEM suppliers of open
system software, independent software vendor suppliers, and end
users, all of whom depend upon a fair open specification process
and will benefit from any process acceleration. This whitepaper
is also addressed to existing consortia, which have already made
substantial contributions to the open systems process, and are
in a perfect position to make even greater contributions with
the support of this acceleration.

This whitepaper has five major sections: First, a demonstration
of how this process will expand choice for the customer of open
system technology; Second, a proposed evolution of the existing
process for specifying and and implementing open system
software; Third, an explanation of how this process would work
in practice; Fourth, a set of principles that apply within the
open system industry; and Fifth, the stages in the life cycle of
software technology. An Appendix describes some tactics for how
to get involved.

The paper proposes no new organizations. Existing organizations
have accomplished much in the open systems arena and will
benefit from these accelerated processes. This paper describes
process and principles. It does not map these onto existing
industry organizations, except for X/Open, whose specification,
certification, and branding process are widely recognized as the
most comprehensive and wide ranging in the industry. These make
an excellent role model for the common open software environment
process.

This overview section concludes by breaking apart the phrase
"common open software environment".



Common.

Users have made it clear that they need system software to be
"plug and play" compatible between vendors. It is not enough for
each software supplier to provide self-consistent software
because that forces users either to make a long-term commitment
to a single supplier or to face a major upheaval if they decide
to change suppliers.

The common open software environment process will make use of
existing processes for specifying and deploying industry
standard software to help users determine when their suppliers
are providing compatible standard software and when they are
not. Specifications and branding will be used to make this
distinction clear.

The primary benefits of common specifications for industry
standard software are application portability and
interoperability. As application writers observe that the same
environment exists throughout the open system industry, and as
they realize the benefit of stable, open specifications, they
will be drawn to make more and more applications available.

Open.

One important use of "open" applies to the inclusive nature of
the process for defining and then approving specifications. Such
a process is open if ample opportunity exits for every voice to
be heard. Openness in this sense is assured in the common open
software environment process by the active solicitation from
working groups for input from the industry, and by the use of
existing consensus-based standards organizations, such as
X/Open, for approving specifications. In order to achieve the
consensus necessary for approving specifications, participants
in the common open software environment process will need to
encourage early and frequent review of draft specifications.

A second important use of "open" applies to technology, where it
has been used generally to signify a programming interface
documented for others to use. Paticipants in the announcement of
the common open software environment intended to clarify the
definition of industry standard "open" technology. Under this
clarification, a technology can be called industry standard open
only if there is available a detailed written specification that
governs correct behavior, and if implementation of complying
software is unrestriced (e.g., it is not required to go to any
particular supplier for the authorized software). Much current
open system software already meets this definition, but some
does not. As a way of demonstrating this new standard, X/Open is
now applying its specification requirements to two technologies
that formerly did not meet this test: OSF/Motif, and Novell
NetWare UNIX Client. Vendors who implement to these
specifications will be able to receive the associated X/Open
brand no matter how they achieve the implementation, as long as
they pass the necessary tests. Industry standard technology is
well specified, is endorsed by a recognized standards
organization and can be implemented to the specification without
encumbrance. Source technology and sample implementations should
be licensed readily and equitably to the industry with equal and
early access for anyone.

 Software Environment.

Software Environment means defining a standards-based
environment for the building and deploying of complex
applications in a hardware neutral way. Thus the common open
software environment process results in products that give users
a choice of hardware vendors that does not limit their software
options.

 ________________________________________________________________
______





                        FOUNDATION FOR CUSTOMER CHOICE

With the success of open systems comes an expanding set of
specifications of widely endorsed and broadly available
programming interfaces. In the open system environment,
customers are able to select a supplier of a particular solution
without limiting their future options for choosing a different
vendor for another solution.

Many vendors in the open software industry are determined to
define fully compatible software interfaces that customers will
find on all platforms bearing a common brand for particular
technologies, with brands controlled by an industry neutral
standards organization.

Like the companies that recently announced a proposed standard
for HDTV, the members of the open software industry are banding
together to propose standards for fully interoperable software.
Then, like the suppliers of HDTV equipment, these vendors will
compete vigorously against each other to sell their own
particular product.

More specifically, the products that result from the open
software process will benefit developers, administrators and end
users by expanding their choices now and for the future.

For application developers, common open software products offer
easier access to an expanded market. Developers will be able to
focus on development needs, not on rationalizing middleware
differences, because specifications and brands will assure them
of the compatibility they require on systems from different
vendors. The efficiency of application creators will increase
along with innovation resulting in improved availability of
application titles for end users.

For system and network administrators, common open software
products offer easier system and network expansion. Again, the
specifications and brands will assure such administrators of the
compatibility of systems from different vendors, thus
accelerating the availability of single point multiplatform
system management capability.

For end users, they bring a consistent look and feel on the
desktop. Interaction with the computer is intuitive and users
can move from platform to platform with the confidence of
familiarity. User productivity will increase through reduced
training and education expense. The common environment will
increase the number of available applications by simplifying
application development, thus benefiting everyone.

Finally, system integrators will have available to them more
competitive choices for compatible systems, since any vendor's
product that conforms to the appropriate specifications and
carries the associated brand will provide equivalent
functionality. Efficiencies realized in systems and network
administration will be passed on to users as lower cost of
support and reduced downtime.

Thus all these customer constituencies will be free to select a
vendor today without limiting their choices for tomorrow. The
open software specifications provide the foundation for choice.
The common open software environment process accelerates the
adoption of standards.
_________________________________________________________________
_____

















                ADDING A CATALYST TO THE OPEN SYSTEM PROCESS

Technical innovation and user requirements have traditionally
driven companies or groups of comanies to create solutions for
the computing marketplace (see slide 1). Companies then competed
for customers on the merits of their individual products.
Sometimes this meant the products would work in multi-vendor
environments and sometimes not, but in any event customers made
their choice evident by their purchases. As de facto standards
emerged from the choice of users, open system providers have
negotiated specifications through standards organizations, and
implementations of these specifications have become available
across the majority of vendor platforms. Thus the amount of
common open software has grown over time.

In an effort to accelerate the availability of open system
specifications, the common open software environment process
describes a catalyst to the open system process. The catalyst is
inserted in two phases of the open system process (see slide 2).
First, at the point before formal submission of specifications
to recognized industry bodies, working groups comprising
representatives from the major interest groups in the open
system industry will try to come quickly to consensus on a
common recommendation. Then submission to the industry standards
organization will allow the specification to be reviewed widely
and approved more quickly. Second, in some cases cooperative
development of an initial implementation can help to further
coalesce the standard to promote compatible product solutions
while accelerating time to market. A complete specification,
with an implementation that supports development of a
comprehensive test suite will be a catalyst to truly consistent
APIs and behavior. This initial implementation will be licensed
and made available readily and equitably to the industry at
large. Both of these catalyst activities directly benefit the
industry by reducing costs, and directly benefit users by
reducing fragmentation.

Acting only as a catalyst to the existing open system process,
this proposal adds no new process stages or organizations.
Existing open system initiatives such as OSF, POSIX, UI, and
X/Open, which were formed to provide open specification forums,
among other services, have laid a solid foundation for the
current acceleration. Their best practices, such as requests for
technology, member working groups and early access to code
should be retained. The acceleration of the common open software
environment process should make it easier to form working groups
with broader representation than heretofore. The opportunity
exists for a significant degree of synergy among these
organizations

.
_________________________________________________________________
_____



                        HOW THE PROCESS WOULD WORK IN PRACTICE

Central to the above process is achieving consensus to endorse a
specification of particular technology behavior which then gets
formalized at a vendor-neutral industry organization. For this
to happen, some forums must exist for conversation at several
levels. This section describes how that might work.

 Formation of ad hoc working groups.

There are plenty of examples of successful multi-vendor
solutions emerging from cooperation among open system vendors,
and many of these have come from ANSI, UI, OSF and the X
Consortium. The companies that announced the common open
software environment spanned memebership of these organizations,
and will work with these groups to come quickly to
recommendations on open system specifications. Ad hoc working
groups may be formed in some technologies as a way to get
started on rapid progress while the existing industry
infrastructure evolves to accommodate the breakdown of old
barriers, while preserving the vital roles of existing
organizations.

There is a well-known trade-off between the size of a group and
its ability to make rapid progress: smaller groups move more
quickly. There is an inverse trade-off between the size of a
group and an ability to reach approval in a broader community:
results of a larger group effort gain broad approval more
quickly because the direct involvement of more affected people
exposes more problems sooner.

The dilemma for the common open software environemnt is to form
working groups sufficiently small to make rapid progress, and
sufficiently large to account for the needs of a broad enough
community. In part this can be accomplished if a smaller group
takes the lead and solicits input from the broader community.
Such working groups should therefore make themselves known by a
public declaration, stating the problem on which they will
focus, who the participants are, and how others can make their
input known. In all cases recommendations of these working
groups will be submitted for widespread review and finalization
by recognized industry organizations. The composition of working
groups should draw upon companies who can foster the success of
the particular areas of technology, and is not limited to any
specific set of companies.

 Preparation of formal specification and certification tests.

Each working group is to be charged with producing a detailed
formal specification that meets the open definition above, and
that can be handed over for consideration by a certification and
branding program at the close of the project. It is expected
that the certification and branding program would be managed by
a neutral industry group such as X/Open or the OMG.

After the specification in finalized by a body such as X/Open,
the working group members could also assist the standards body
by providing it, either directly or indirectly, with a set of
certification tests of sufficient completeness and quality to be
used in a branding program. This body would evaluate the tests
and coordinate as appropriate with the working group to reach
the necessary test quality. After both the specification and the
tests are accepted, then a complete branding program can begin,
and individual vendors can cite conformance.

The catalyst added by the common open software environment
process is the discipline of requiring working groups to define
and publish a draft specification, to provide test suites
appropriate for branding, and to deliver an equitably licensed
sample implementation.

 Sample implementation.

Implementations of the specification could come to the
marketplace in any number of ways. In some cases, industry
members may want to cooperate in the development of an
implementation of the specification. In others, one or more
individual vendors might have implementations that others could
license. Early availability of an implementation for use by
multiple vendors can help achieve a solution with uniform
compatibility and consistent behavior. In all cases, the common
open software environment process requires a readily licensed
sample implementation, available consistently to the industry.
In any case, any vendor is free to develop its own
implementation of the specification.

 Key points of common open software environment process

There are five key points to the common open software
environment process, reflecting how it works to provide a
catalyst to the existing open system processes:







1) System suppliers come together in a working group to
accelerate the recommendation of a draft specification, in a
specific technology area.

2) Each draft specification will be submitted to a recognized
industry body for broad review under establised processes, and,
if accepted, will provide an unencumbered specification to which
anyone can build an implementation.

3) One or more sample implementations should exist for each
specification so that any interested vendor can exercise a
make/buy decision. These implementations should be readily and
equitably licensed to the industry.

4) Test suites should be available for certification and
branding to the specification.

5) The process allows for different companies to participate for
each technology area.
_________________________________________________________________
_____



                                PRINCIPLES OF THE PROCESS

This section describes the acceleration from the point of view
of the participants: contributors to open system specifications
and vendors of open system products.

 Contributors.

To demonstrate a commitment to the principles of the common open
software environment process, suppliers of open software
technology would:

        - Accelerate multi-vendor definition of a draft specification
ahead of  the standards setting

         organization if necessary, by participating in  ad hoc groups
representing a critical mass

         of the open system industry.

        - Submit an unencumbered draft specification to an industry
review and  adoption process,    and abide by the decisions of
specification reviews.

        - Ensure their implementation conforms to a rigorous
specification,  certification, and

         branding mechanism.

        - Allow the building of unencumbered (no royalty) common
behavior  implementations

         to the specification. (Any necessary patent licenses  should
be openly licensable

         on reasonable terms and conditions  consistent with standards
organization practice.)

        - Encourage availability for open licensing of a sample
implementation  and certification

         test suites, including early access to source code to  ensure
rapid deployment.

        - Compete vigorously against each other on the basis of quality
 implementation, service,

         support, price, and other added value.

 Vendors.

This same set of principles can be extended to what vendors of
open system products can expect of the common open software
environment process. Vendors of products that emerge from the
common open software environment should expect:

        - That the specification will provide sufficient detail for
them to  build an implementation

        from scratch and that if they do so they will  have no
royalties to pay for use of the

        specification.

        - To be able to brand their implementations to the available
specifications so that their

        customers know of their compatibility with  other open system
vendors.

        - That vendors, working together or separately on
implementations based  on the open

        sysetm specification, will be encouraged to make such
implementations available for

        licensing, including early access.

The principles in this section tend to apply differently during
particular stages of the life cylcle of software, and open
systems vendors engage in the process differently at different
stages. The next section, taken together with the appendix,
descibes how to be a full participant in the common open
software environment process at all stages.

 ________________________________________________________________
______



                SOFTWARE LIFE CYCLE AND STAGES OF THE PROCESS

Software technology passes through roughly four stages in its
life cycle as it relates to the common open software environment
process. Economics of product differentiation drive some
software forward through these stages, as the value of
differentiation decreases and the value of commonality increases.

For the technology that ultimately becomes industry standard,
the following four stages apply from inception through industry
standardization:



1) Innovation - Vendors market a variety of solutions, often
incompatible, trying to bring new function to market quickly, to
meet a range of user requirements

.

2) Common Direction - User demand for commonality drives
innovative approaches into a more consistent direction

.

3) Deployment - Vendors produce a draft specification, show
industry endorsements, produce sample implementation(s), produce
rigorous test suites.



4) Availability - Formal approved specification exists and
certification branding is available. Vendors compete against
each other on the basis of quality, service, price, and other
added value.

The remainder of this section comments more on each of these
stages. The chart in slide 3 shows in which phase some sample
technologies might fit in the taxonomy today.



 Innovation

In the innovative phase, many different solutions may exist and
users can select those that best meet their needs but may be
constrained by incompatibility between vendors. Vendors accept
the high risk of developing products because of the potential
reward. Users accept a corresponding high risk because the
technology may become obsolete. A basis of commonality has not
been established. This may be because the marketplace has not
yet clarified the scope and priority of user needs or decided
which solutions best meet those needs. Or the technology may be
one where a variety of different optimization points are needed
to address a range of requirements. Thus both users and vendors
benefit from innovation as long as the economics support it. The
process described in this whitepaper addresses only the software
that moves out of the innovative phase with a recognition of a
demand for a common direction.



 Common Direction.

As technology matures, users see the value in, for example,
exchanging data between solutions from different vendors. Thus
the value of commonality grows to equal the value of
differentiation in elements of some technologies. In the face of
this demand, vendors may confer to set a common direction, as a
catalyst to the open system process.

The common open software environment process allows for any
group of vendors to initiate action toward a common direction,
in fulfillment of a perceived user demand. It becomes a common
direction only when a critical mass of vendors across the
industry give it their support, while retaining their ability to
address independently the broader range of differentiated user
needs. Clearly, if sufficient vendors withhold support, their
vote signals continued differentiation. Leadership of a common
direction can come from any quarter, often initially through
meetings of a few vendors. An action becomes a common direction
only with an ample following made evident through public
endorsements, and eventually through votes at industry
organizations that formalize a specification.

A common direction can take any of several forms:



- Vendors could decide to integrate some existing technology and
to  write a new specification (e.g., the common desktop
environment).



- Vendors could decide to endorse a de facto standard (e.g.,
Motif).



- Vendors could set up a work group to write a draft
specification of a  common set of Application Programming
Interfaces.



 Deployment.

In technologies where commonality has a critical mass of
support, it behooves the industry to move as rapidly as possible
to a specification, implementation, tests, and a brand. This can
be accomplished in many different ways, ranging from a single
company writing all components and licensing it to others, to a
collection of cooperative development and test agreements
between companies who decide to share the cost and the ownership
(e.g., the common desktop environment). The deployment stage
should include provisions for early access of specifications,
implementations, and tests to facilitate broad, rapid deployment
across the industry.



 Availablity.

After a specification is approved and adequate test suites are
available, a certification branding program can begin, and a
support structure must exist for resolving ambiguities in the
specification or in the tests. Thus vendors will compete against
each other on the basis of product availability, quality,
service, price, and other added value. All certified
implementations would be permitted to carry the brand, and would
be expected to exhibit the specified behavior.
_________________________________________________________________
_____



                                CONCLUDING REMARKS

The common open software environment process has been proposed
as a way to accelerate the adoption of standards for the open
system industry. Thus it is neither an initiative nor a group
nor a club nor a consortium.



The common open software environment process is an open system
process, a set of principles, a commitment to catalyze, and a
mind set to accelerate.





The purpose of this whitepapaer is



        - to lay out the principles for a common open software
environment in  which contributors      and vendors cooperate for
the growth of the  industry and for the benefit of users, and



        - To describe a process that embodies this cooperation.



Now the task is to build support for these principles and
processes. The UniForum Association has volunteered to be a
focal point for your feedback. Please contact Ed Palmer at
408-986-8840 ex. 12, or by email to [e-mail].

 ________________________________________________________________
______



                                        APPENDIX

Tactical Scenarios



The body of this paper outlines some principles and strategies
for the common open software environment process. These are
necessary but not sufficient to document how vendors might
engage for the best advantage to themselves and to open systems.
This appendix proposes a tactical response for several
scenarios, with a focus on setting common directions, the
catalyst in the common open software environment process.



 1. Starting a New Common Direction Activity



Suppose your company has some state of the art expertise in a
technology in which commonality will be required in the near
future for its market to continue to grow. How should you
introduce a common direction, and how can it follow the common
open software environment process?



Here are some suggested steps:

 1) Test your assessment of the business opportunity and the
technology   against the principles described in this paper.

        a. Demand for commonality

        b. Key multi-vendor agreement

        c. Commitment to open specification

        d. Availability of sample implementation and tests



2) Become familiar with the principles of the common open
software   environment process as described in this document,
and engage others   on the basis of these principles.



3) Identify and engage other companies. Work with existing
working groups   or use an RFP or your own networks to find
like-minded vendors. Seek   to build critical mass of both large
and small vendors, while keeping   your group small enough to be
manageable.









 2. Conducting a Common Direction Setting Activity



Suppose there is now a group formed which intends to set a
common direction, and you are one of the initial memebers. By
voluntarily participating in a common direction setting group in
the open software industry, you assume responsibility for
accelerating a technology to a specification that will be widely
adopted and implemented. Such adoption can only happen if the
requirements of vendors both inside and outside the direction
setting group are adequately accounted for. Accordingly, the
following tactics are directed at both rapid progress and broad
participation.



Here are some suggested steps:



1) Seek input from companies not included in your small group to
be   certain that all requirements are understood and no
opportunities for   input are overlooked.



2) Identify an appropriate vendor-neutral standards organization
and   begin conversation with them regarding your intent to set
common   direction and to build a draft specification, if

applicable.



3) At an appropriate time make a press announcement citing the
common   open software environment process and seek public
endorsement from a   broad spectrum of open system vendors for
the direction you are   setting, including others who have
endorsed the common open software   environment process.



4) Prepare a draft specification for submission to the selected
standards   organization. Adjust the specification as needed to
accommodate the   review process. Work towards a passing vote
through member consensus.



5) Follow through with you implementation of the specification.
Engage   other companies in a joint cooperative development, if
desired.   Provide technology licenses, including early access,
to other vendors.



6) Facilitate broad availability of implementations to the
specification.



 3. Joining an Existing Direction Setting Activity

Suppose a group of companies has made a public announcement of a
direction-setting activity and you wish to be involved. You
agree that commonality has become necessary in this technology,
and it is a vital part of the future of your business.
Accordingly you wish to facilitate the adoption of a common
direction, and you wish to have your own product implementation
in the marketplace as early as possible. How can you position
your company either to influence the common direction, or at
least to take maximum advantage of it?



Here are some suggested steps:



1) Contact one or more of the companies that announced the
common   direction setting activity and request status reports.

2) Make your requirements known to the participants in the
common   direction setting group.



3) If your wish to influence the common direction, prepare a
position   paper or presentation. Approach one or more of the
companies to   provide input, recognizing that the companies
will be looking for ways   to accelerate the definition of a
common direction, and recognizing   as well that not all
proposals can be incorporated. Proposals that   either bring
missing technology or add significant contribution within   the
scope of the project would be the most favorably received.



4) Seek to be involved in any press releases that come from the
common   direction group, stating your involvement with and
endorsement of the   activity.



5) Contact the selected vendor-neutral standards organization
and register   with them at a level appropriate to your desire
for review. Participate   in their review and adoption processes.



6) Consider developing a sample implementation, either alone or
working   with other companies. Alternately, take all available
early access of   source code and proceed aggressively to build
you own product   implementation.



4. Other Stages of Software Life Cycle



This appendix has focused on the setting of common directions,
which is a primary catalyst activity in the common open software
environment process. Similar steps can be taken to engage with
other vendors in the evolution of technology in all other stages
as well.

 ________________________________________________________________
______